…tibility

…lTools

This is a rethinking of the initial API proposed in `languageModelToolSupportsModel.d.ts`.

1. This switches to `models?: LanguageModelChatSelector[];` to control enablement.
   definitely open to switching this out, but I think a synchronously-analyzable
   expression is important to retain the data flows in core without too many races.
2. The extension is able to define a tool at runtime via registerToolDefinition. This
   should let us have entirely service-driven tools from model providers without
   requiring a static definition for each one. We can also have model-specific
   variants of tools without a ton of package.json work for each variant of the tool
   (as initially proposed using `when` clauses)

This then propagates that down into the tools service. Currently I have this as just
compiling to a `when` expression once it reaches the main thread. Then, for the tools
service, it takes an IContextKeyService in cases where tools should be enumerated,
and the chat input sets the model keys in its scoped context key service. This allows
the tools to be filtered correctly in the tool picker.

I initially thought about allowing multiple definitions be registered for the same tool
name/id for model-specific variants of tools but I realized that gets really gnarly and
we already have a `toolReferenceName` that multiple tools can register into.

Todo for tomorrow morning:
- Tools don't make it to the ChatRequest yet, or something, still need to investigate
- Need to make sure tools in prompts/models all work. For a first pass I think we can
  let prompts/modes reference all tools by toolReferenceName.
- Validate that multiple tools actually can safely share a reference name (and do
  some priority ordering?)
- General further validation
- Some unit tests

* chat: wip on model-specific tools

This is a rethinking of the initial API proposed in `languageModelToolSupportsModel.d.ts`.

1. This switches to `models?: LanguageModelChatSelector[];` to control enablement.
   definitely open to switching this out, but I think a synchronously-analyzable
   expression is important to retain the data flows in core without too many races.
2. The extension is able to define a tool at runtime via registerToolDefinition. This
   should let us have entirely service-driven tools from model providers without
   requiring a static definition for each one. We can also have model-specific
   variants of tools without a ton of package.json work for each variant of the tool
   (as initially proposed using `when` clauses)

This then propagates that down into the tools service. Currently I have this as just
compiling to a `when` expression once it reaches the main thread. Then, for the tools
service, it takes an IContextKeyService in cases where tools should be enumerated,
and the chat input sets the model keys in its scoped context key service. This allows
the tools to be filtered correctly in the tool picker.

I initially thought about allowing multiple definitions be registered for the same tool
name/id for model-specific variants of tools but I realized that gets really gnarly and
we already have a `toolReferenceName` that multiple tools can register into.

Todo for tomorrow morning:
- Tools don't make it to the ChatRequest yet, or something, still need to investigate
- Need to make sure tools in prompts/models all work. For a first pass I think we can
  let prompts/modes reference all tools by toolReferenceName.
- Validate that multiple tools actually can safely share a reference name (and do
  some priority ordering?)
- General further validation
- Some unit tests

* key selected tools based on reference name

…king logic

…tracking after a rename refactoring freshly

This reverts commit 13a39cc.

…sionsWelcome.ts

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Add usage data to chat result api

* Start prototyping status icon

* Cleanup old context widget

* Cleanup widget

* Grow outwards

* Some cleanups and refacotors

* Make actions contributable

* Add action header

* Cleanup action rendering

* Add sub categories of token usage

* cleanup diff

* Handle copilot feedback

Implement post rename refactoring for NES

* Log usage of Add Element to Chat

* Small change

…d styles (#289701)

* fix: adjust position calculation for inline chat widget when not anchored above

* fix: improve position calculation for inline chat session overlay based on selection and diff changes

* fix: update inline chat session overlay to improve progress indication and remove pulse animation

* fix: rename progress elements to status for clarity and update related styles

Context key fix for welcome view

* chore: fix casing

* chore: fix more casing

tool picker alternative position

Support tool filtering by model

…ions (#289731)

* setting for attaching applying and referenced settings

* update

* tests

* fix tests

* Update src/vs/workbench/contrib/chat/common/promptSyntax/utils/promptFilesLocator.ts

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* fix

* fix

* fix

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

…ine-new-setting

…ew-setting

Add inlineChat.defaultModel setting

…grated Browser (#289565)

* Setting to open localhost links in Integrated Browser

* Apply suggestion from @Copilot

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Rename

* Log telemetry for open method

* Distinguish commands with and without URL

* use isLocalhostAuthority in other use too

* Add descriptions for source values

* PR Feedback

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

…nal (#289706)

…ditor area when hiding side bar / panel (#289758)